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(57) Abstrstei: The invention relates lo a metJiod for managing radio resources alloeated by the radio nelworis controller of an 
UTRAN radio aeeess networkn Said resources support a plurality of ser\ iee requests eiicb of which is identified by a jservice support 
reqijest for radio ^cess trarsniiaed by a core network aiid describes an QoS requested in the form of a totality of RAB parameters 
defined by mapping with the con-espondiiig QoS paranieters of the core network. The controller is ^Ksed for disttibuting lesources 
amongst different suppojt sei-vices and for modulating and allocating said resouice$ according to a priority level associated with each 
suppoit sei-vice. The pi ioriJy level is defined by the priority level subparanieter of the RAB Allocation Retention Pj^oriiy parameter 
whose value is determined by taking into consideradon the said QoS Allocation Retention Priority parameter of the core network 
and the value of at least one QoS parameter associated with a type of service. 
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En c.e. qui conccme Itts codes d, deux le^ttras fit autms ahrevia- 
Hons, se refere.r aux "Notes ttX}}Ucatives relatives aux codes et 
ahreviatinns" figurant au d0>ut dr? <ihaqi4g numero oidinaire de. 
la Gazette du FCT 



(57) Abrege : Llnvention concenie proc^^ de gestion des ressoarces radio allou^s par on control but der&eau radio d'un rfeseau 
d*accfes de type UTRAN, lesdU^ ressources supportant une plurality de demandes de service jdentifi^es chacune par une requSie de 
service support d'acc&s radio tmvoy^e par 1e r^seau coeur el d^crivant la QoS requise soas forme d'un ensemble de parametres RAB 
dermis par une raise en coitiespondance avec des paramfeEres de QoS correspondani: du r^seau coeur, ledit comrOlear 6tant pr6vu 
pour nSpartir Jes nsssources enii^ les differents services supports et pour moduler I'allocation desdites ressources selon un niveau de 
prionUJ atiKocie a chacun deiidils services supports, lediL niveau de priorite elant delini par le sousst-param^lne « priority level » du 
parameire RAB <t Allocation Retention Prionly *, dont la valeur est d6l*jrmin<^e en prenant en coinple d'une part, la valeur dudit 
pardmeire de QoS «: Allocation Retention Priority » du itSseau coeur el, d'auU-e part, ia valeur d'au moins un param&tre de QoS He au 
type de ^fervice. 
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PROCEDE DE GESTION DES RESSOURCES RADIO DANS UN 
RESEAU D' ACCES RADIO DE TYPE UTRAN 



5 Uinvention conceme de maniere g6nerale le domaine des 

telecommiinications et se rapporte plus parttcuUerement a wi px'ocede de 
gestion des ressources radio au niveau reseau d'acces dans un reseau de 
communication mobile en mode paquet et en mode circuit du type UMTS. 

Le precede scion riavcntion est done prevu pour s*appliquer aux 

10 reseaux mobiles utilisant la technologie UMTS, normalisSe dans le cadre de la 
norme 3GPP, Dans un souci de ne pas sracharger la description, rat glossaire 
comprenant la definition de rensemble des acronymes utilises est prevu a la fin 
de la description, ou le leeteur pourra utilement se reporter. 

La norme UMTS specific un nouveau reseau d'acces mobile : 

15 rUTRAN^ qui permet d'of&ir aux abonn6s d*un operateur mobile un acces a 
des services bases sur IP (messagerie electronique, telechargement de fichiers^, 
consultation de sites Web oxi WAP) ou des services circuits (telephonie, 
visiophonie). A I'heure actuelle, I'UMTS est phas6 en diff6rent^ versions, 
encore appeiees "releases^' selon la terminologie anglo-saxonne, et notamment 

20 la version denomm^e Release 99, h laqueile la description qui va suivre fait 
plus particulierement reference. 

En tenne d»architecture, le reseau UMTS est divisible en deux sous- 
reseaux, ie reseau cceur CN et le reseau dracoes radiOj, aussi appel6 UTRAN, 
tels que repr^entes a la figure 1 . 

25 Le reseau d'acc^ iaclut une pluralite de statioi^ de base radio Node Bj 

prevues pour communiquer avec des equipements utllisateurs UE a travers une 
interface radio utilisant des ressources radio alienees par un controieur RNC. 
L' architecture hierarchique, dans laqueile une entite controle plusieurs entites 
de niveau inferieur est identique au reseau d'acces radio du GSM. Le 

30 controieur de reseau radio RNC y tient la place du controieur de station de base 
(BSC) du GSM, Toutefois, les technologies radio employees pour transporter 
les informations sont difierentes, 

Le reseau coeur CN UMTS comprend quant a lui deux domaines 
distincts : le domaine circuit CS, qui comprend tous les service li^s a la 



wo 2005/084061 



2 



PCT/FR2005/000 130 



telephoKie, et le domaine paquet PS qui comprend tous les services li€s h la 
commutation de paquets. 

Au niveau du reseau coeur, on retrouve le HLR qui est une base de 
donnees commune aux deux domaines, dans laquelle soiit stockees les 
5 infonnatxons relatives k chaque abom6 de l'op6rateur du reseau : le numero 
d'appel de I'abonne, I'identite du mobile ainsi que les informations de 
rabonnement Le HLR contient egale^ent entre autres, les informations de 
qualite de service li6es aux abonnes et aux services, qui seront d6finies plus 
loin dans la description. Ainsi, c'est a partir de cette base de donnees que 
10 s^effectue la gestion des abonnes mobiles au sein du reseau. 

Le reseau cgbut h&erge egalement les conmiutateurs de circuits MSG et 
les commutateurs de paquets SGSN, Ces nceuds de service Ax reseau coeur 
assurent la gestion du lien de communication avec le reseau d*acces. Us 
stockent le profil de rabonn6 issu du HLR et effectuent un contrdle des 
15 resources reseaux dem^dees par I'abonne, 

Au niveau du domaine paquet^ le SGSN est associe avec un autre nceud 
de service, le GGSN, qui joue plus particulierement le role de passerelle vers 
les reseaux h commutation de paquets exterieurs (internet, etc*,,.)* Le reseau 
coeur UMTS> en oe qui conceme le domaine paquet, est done interconnecte 
20 avec Texterieur via une passerelle, le no&ud de service GGSN, qui contient les 
informations de routage permettant au mobile de communiquer avec un r6seau 
exteme, notamment le reseau Internet, tout en assurant la securite. Pour 
pouvoir envoyer les informations au mobile, le GGSN utilise alors 1' autre 
noeud de service, le SGSN, qui g^re la mobility au niveau du reseau coeur, 
25 Tauthentification et le chiffrement. Ces elements de reseau integrent des 
fonctions de routeur IP et constituent tm reseau de type reseau IP, 

Au niveau du domaine circuity et de la meme fa9on qu'expHqu^ en 
relation avec le domaine paquet, le MSC est associS avec un autre noeud de 
service, le GMSC, servant de passerelle vers des reseaux fixes de type RNC, 
30 RNIS, etc.,„ 

En Release 99, tous les services UMTS sont supportes par quatre 
classes de trafic nomialis6es comme suit : "Conversational", "Streaming", 
"Interactive" et "Background", 
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Les classes "Conversational" et "Streaming" sent principalement 
prevues pour transporter des flux temps reel comme de la voix ou de la video. 
Toutcfois, pour la classe "Streaming", correspondant a une utilisation du type 
un utilisaterur regardant (on eoontant) un flnx vid6o (ou andio) temps r6el, la 
5 contraiute snr les delais de transfert de donnees est plus faible que pour la 
classe Conversational. 

Les classes "Interactive" et "Background'* correspondant k des services 
non temps reel et sont quant k elles pr^vues pour Stre utilisees dans le cadre 
d'applications Internet traditionnels telles que la navigation, le courrier 
10 electronique^ les application FTP, Ces demiferes classes 6tant non temps r^el, 
elles offrent un bien meiUeur taux d*erreurs grSce k des proc6dfe de 
retransmission et de codage. 

On a vu que Finvention concemait la gestion de la repartition des 
ressources, et plus particulierement des ressources radio, dans le reseau 
15 d'accSs. Une telle gestion ndcessite la prise en compte des param^tres de 
qualite de service (QoS) associes a une demaade de service. 

Les parametres de QoS du service support UMTS d6crivent ainsi le 
service rendu par le reseau UMTS h Tutilisateur du service support. Le profil 
QoS, forme par Tensemble des parametres de QoS, specifie ce service. Ce sont 
20 done des parametres normalises permettant de definir les caracteristiques 
principales d'un flux de donnees sur le reseau, notamment en terme de d^bit, de 
type de trafic^ de priorite, etc.. Ces donnees sont stockees dans le profil de 
rabonne dans ie HLR et transmises, grace k diff6rentes procedures, aux entit^s 
suivantes: SGSN et MSG. 
25 Le profil QoS d*un abornie dans le domaine paquet correspond en fait a 

la limite haute autorisee par mpport aux valeurs specifiques demandees par 
I'abonne. Le profil QoS peut aussi correspondre a un profil par defaut configure 
par Toperateur. 

Parmi ces parametres de QoS qui sont specifics dans im profil QoS, on 
30 trouve principalement ; 

- "Allocation Retention Priority*' (ARP) : ce paramfetre de QoS permet 
d'effectuer une priorisation du trafic entre plusieurs abonnes poiir T allocation 
et la retention des services supports UMTS. Un parametre de ce type est 
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Specific respectivement pour chaque domaine : le domaine paquet et le 
domame circirit. 

" "Traffic Class": ce parametre de QoS indique la priorite liee au type 
de service, Comme on Ta vu, en Release 99, tous les services sont supportes 
5 par quatre classes de trafic. AiissL, ce parametre de QoS pent prendre les 
valeurs **Coiiversationar' (correspondant a im niveau haute priorite, puisque 
Texigence de temps reel est tres importante), "Streaming", "Interactive" et 
"Background" (basse priority). 

- "Traffic Handling Priority" (THP): ce parametre de QoS peniiet de 
10 preciser le niveau de priorite pour la classe de trafic "Interactive", Ce parametre 

peut prendre trois valeurs et permet ainsi de prioriser les profits de type 
« interactif » les uns par rapport aux autres. 

Parmi ces parametrcs, on peut encore citer, a titre inforaiatif, car non 
utUisfe dans le cadre de la presente invention ; 
15 - "Transfert delay": ce parametre de QoS donne le deiai maximum lors 

du transfert d^un paquet. II est utilise pour les services temps reel seulement. 

- "Guaranteed bit rate": ce parametre de QoS indique le debit garanti 
lors du transfert d'un paquet n est utilise pour les services temps reel 
seulement 

20 - "Maximum bit rate^' : ce parametre de QoS indique le debit maximum. 

L'ensemble des paramfetres de QoS pr6cites sont d6finis dans le cadre de 
la norme de telecommunication 3GPP, Toutefois, leur utilisation n'est pas 
nomialisee. 

En UMTS Release 99, au niveau du HLR, la norme prevoit la 
25 possibilite d' avoir un niveau de priority dans les donn^es d'abonne pour des 
services paquet et circuit. C^est le parametre « Allocation Retention Priority » 
(ARP) qui est utilise a cet effet Ce parametre est renseigne au niveau du HLR 
dans le reseau coeur pour chaque contexte PDP souscrit pour le domaine paquet 
ou par abonne pour le domaine circuit, 
30 Le parametre ARP permet done de defmir une priorite entre les abomies 

pour r allocation/conservation des ressources radio. Le param&tre ARP est 
utilise dans le MSG, le SGSN, le GGSN et peut prendre trois valeurs dans le 
reseau coeur, respectivement : priorite 1, priority 2 et priorite 3^ la priorite 3 
etant la plus faible. 
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Le parametre ARP est envoye au RNC de TUTRAN sous forme de 
quatre sous-parametres, pour associer un niveau de priorite a une 
conimumcation correspondant a une demande de service d'un aboiine. Ce 
parametre est done transform.^ en quatre sous-paramtoes au niveau du r6seau 
5 coeur pour Stre envoye au RNC de TUTRAN : ''Priority Level", "Pre-emption 
Capability'^ ^Tre-emption Vulnerability^ et "Queuing" allowed", dont les 
valeurs d6coulent du parametre ARP du rSseau coexir, Ces quatre sous- 
parametres sont definis plus precis^ment dans la partie TS 23.413 de la norme 
3GPP- 

10 A partir des parametres de priorite envoyes par le r^seau coeur CN^ 

rUTRAN doit Stre capable de r^artir I'integralit^ de ses ressources (k savoir 
les ressourc^ radio, les ressources de transport et la capacite de traitement) 
entre les differents utilisateurs du systeme. 

Une procedure d' activation d'vm contexte PDP est d^crite en reference k 

15 la figure 2. EUe perniet a un terminal mobile MS de demander la memorisation 
d^n contexte PDP dans le SGSN et GGSN et ainsi de reserver des ressources 
dans le reseau cceur pour rexScution du service souhait6 par i'abonn^, Lors de 
Tactivation d^un contexte PDP, les differents noeuds du iSseau UMTS resolvent 
les informations de qualite de service liees au contexte PDP demande et a la 

20 souscription de Taboimej en particulier la classe de trafic et la priorite de 
r abonne, definie par le parametre ARP* 

L^nformation correspondant a la priorite de Pabonne, c'est-a-^dire ie 
parametre ARP contenu dans les donnees definissant les contextes PDP 
souscrits par rabonn6, est transmise au SGSN lors de la mise h jour de la 

25 localisation de rabonne. Cette information est ensuite transmise au GGSN lors 
de r activation d^un contexte PDP par Tabonne, puis au RNC sous la forme des 
quatre sous-pamm^stres definis plus haut. 

La procedure d' activation d*un contexte PDP a done lieu lorsque Tabonne 
souhaite envoyer ou recevoir des donnees sur le reseau pour ^execution d^un 

30 service auquel il a souscrit et est declenchee a Tinitiative de Fabonne mobile, 
permettant air^i au terminal d'etre connu du noeud de service GGSN qui realise 
rinterconnexion avec le reseau exteme demande par rabonne. A Tissue de cette 
procedure deactivation d^un contexte PDP, le profit do qualite de service 
correspondant est done 6change entre les diffdrents noeuds du reseau et la 
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transmission de donn^es entre le reseau UMTS et le riSseau exteme 
correspondant an service demande par Tabonne peut alors d^buter. 

Dans une premiere etape, ie terminal mobile MS demands Tactivation 
d'un contexte PDP a son SQSN d'attache en pr^cisaiit la QoS souhaitee, Le 
5 SGSN peut modifier la QoS demandee suivant les donnees de sonscription et 
d'axttres parametres. 

Dans des deuxieme et troisieme etape, le SGSN relaie la demande au 
GGSN avec les paramtoes de QoS qu'il a modifiee. On parle alors de QoS 
negociee. Le GGSN peut alors re-modifier la QoS et la renvoie au SGSN. 
10 Dans des etapes 4 et 5, le SGSN demande au RNC d'allouer les 

ressources radio niScessaires en d&rivant la QoS negociee sous forme d'une 
requete de service support d*acc6s radio comprenant un ensemble de 
paramdtres RAB, qui comprennent notamment la class© de trafic et les quatre 
sous-parametres issus du parametre ARP du reseau coeur* Les parainetres RAB 
15 sont defmis dans la section 9.2.L3 de la norme 3GPP TS 25.413 v4,0.0. 

Le RNC prend en compte la demande et, a partir dea parametres RAB, 
eitectue un calcul des ressources radio necessaires pour le support de cette 
demande de service. II verifie si les ressources necessaires sont disponibles et, 
si ce n*est pas le cas, il doit gerer la pdnurie de ressources en fonction des 
20 parametres des services deja en courts d'appel et des parametres de ia nouvelle 
demande, Le RNC peut alot^ accepter ou refuser le service support d'acces 
radio demande. 

Dans une sixieme etape, le SGSN accepte la demande du mobile en lui 
renvoyant la qualit6 de service qu'il a obtenue sur le reseau 

25 Au niveau du domaine circuit, prenons Texemple d'une demande 

d'appel sortant de type visiophonie. Dans une premiere etape, le mobile envoie 
sa demande de service au reseau coeur* Les caracteristiques de QoS demandee 
sont coiitenues dans le champ relatant 1^ capacites du r&eau support (Bearer 
Capability), Ce dernier precise le debit, le type de connexion souhaitee, . . Dans 

30 une deuxieme etape, la demande est relay^e vers ie reseau fixe, type RNIS. 

Enfin, le reseau ccEur envoie sa demande d'allocation de ressources 
radio correspondante en d6crivant la demande de service sous forme de 
parametres RAB, Le RNC effectue un calcul des ressources necessaires pour le 
support de cette demande de service, II verifie si ces ressources sont 
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dispombies et, si ce n'est pas le cas, il doit g6rer la p^nurie de ressources en 
fonction des parametres des services deja en cours d'appel et des paramdtres de 
la aouvelle demmide. Le RNC peut alors accepter ou rejeter le RAB demaade* 
Une contrainte importante k prendre en compte tient ea ce que 
5 rUTRAN doit e£re capable de repartir Tintegralite de ses ressources 
(ressources radio, ressources de transport, capacite de traitement) entre les 
diff^rents utilisateurs du systeme a partir des parametres de priorite envoy^s 
par le CN, Pour cela, ime procedure de preemption^ prevue par ia nonne, peut 
etre mise en oBuvre pour faciliter I'acces aux ressources pour des utilisateurs ou 
10 des s^rvaces consideres par I'operateur du reseau comme prioritaires iorsque les 
ressources ne sont pas dispombies pour r^pondre a la QoS requise. 

Les parametres de priori te envoy es par le CN font partie des parametres 
RAB et sont les suivants ; 
-Traffic Class 
15 -Traffic handling Priority 

-Allocation Retention Priority, forme par les quatre sous-paratn^tres : 
-Priority Level 
-Pre-emption Capability 
"Pre-emption Vulnerability 
20 -Queuin g Allowed 

Ces differents parametres peuvent permettre de dSfinir m niveau de 
priorit6 pour P allocation des ressources entre les differents services support 
d'acces radio RAB correspondant a des demandes de services venant du reseau 
cceur, De plus, quand les ressources necessaires pour r6pondre k une nouvelle 
25 demande de service sont insuffisantes ou ne soat pas dispombies, la procedure 
de preemption prevue par la norme pourra Stre mise en oeuvre en fonction de ce 
niveau de priority. 

La procedure de preemption se traduit concretement par la mise en 
oeuvre d'algorithmes permettant une diminution des ressources allouees a un 
30 utilisatenar donne de sorte k disposer de ressources suffisantes pour repondre a 
une demande prioritaire. 

Le schema de la figure 3 illustre a cet egard les differents niveaux 
d'^utilisation des ressources C de FUTRAN qui correspondent aux differents 
sc&iario de charge du r6seau an cours du temps t* Ces diff6rents scenarii 
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permettent de definir les cas d 'utilisation de la proc&iiire de preemption, Le 
seuil S d^limite la zone consideree comme zone de surcharge* II est a noter que 
pour certains lypes de ressources, on ne pourra jamais depasser ce seuil 
(pliysiquement, toutes les ressowces sont utilisees, on parte alors de ressources 
5 d^nombrables.) Inversement, pour d'autres types de ressources, ressources 
indenombrables. le seuil de surcharge S pourra etre dcpasse pendant une 
certaine periode de temps. 

Dans une zone 1, dite zone normale, aucune restriction n'existe quant h 
Tutilisation des ressources, II y a en effet suffisamment de ressources 

10 disponibles pour repondre a une nouvelle deroande deallocation de ressources 
et la procedure de preemption n*a pas lieu d'etre utilisee. Autrement dit, la 
somme d^ ressources C actuellement utilis6es sur le reseau et des ressources 
necessaires R pour satisfaire la nouvelle demande d' allocation de ressources 
avec la qualite de service rcquise, est inferieure a la valeur du seuil S qui 

15 delimite la zone de surcharge. On v6rifie done : C4'R<S 

Dans une zone 2, dite zone proche de la surcharge, il y a encore des 
ressources disponibles^ mais ces ressources disponibles sont insuffisantes pour 
repondre a une nouvelle demande d' allocation de ressource. C'est-a-dire que le 
niveau d^ utilisation des ressources C dans le reseau est inferieur au seuil S qui 

20 delimite la zone de surcharge, mais si l*on considere en plus dans la totalite des 
ressources utilisees, les ressources necessaires R pour satisfaire la nouvelle 
demande d'allocation de ressources avec la qualite de service requise, on passe 
dans une zone referencee 3, dite zone de surcharge* Soit ; C-t"R>S et C<S 

Dans une telle situation, plusieurs strategies peuvent etre envisagees 

25 pour repondre a la nouvelle demande d'allocation de ressources sur le r6seau : 

- soit la demande est purement et simplement refusee, 

- soit la demande est acceptee^ mais avec ime quantite de ressources 
allouee inferieure a celle demandee de sorte a ne pas rentrer dans la zone de 
surcharge, 

30 - soit la demande est accept^e avec sa qualite de service demandee et la 

procedure de preemption est declenohee pour recuperer les ressources 
necessaires pour repondre exactement h la demande* 
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Dans la zone de surcharge 3, le niveau d'utilisation des ressoi^rces est 
egai ou superieur au seuil qui delimite la zone surcharge, Dans cette 
situation, on verifie la relation suivante : C > S 

Autrement dit, dans ceftte zone, la charge aotuelle dans le reseau, qni 
5 correspond au niveau de ressources utilisees a cet instant:, ^st supeiieure ou 
6gale h la valeur du seuii qui delixnite la zone de surcharge, Le reseau se trouve 
alors en surcharge ou saturation, Dans cette zone 3^ toute nouvelle demande 
d'allocation de ressources, soit suite k Fetablissement d*un nouveau RAB, soit 
suite h une demande de reconfiguration d'un RAB pour repondre a une 
10 evoiiition dix trafic de ce RAB parti culier deja admis dans le reseau ou h une 
mobilite de ce RAB, est rejet^e jusqu'a ce que le niveau de charge revienne en 
dessons du seuil de surcharge. 

Ainsi, on s^apergoit que dans certaines circonstances, le niveau courant 
d'utilisation des res^urc^s de TUTRAN rend problematique la reponse a une 
15 nouvelle demande d'allocation de ressources avec la qualite de service requise, 
Le declenchement d'une procedure de preemption visant justement a recuperer 
les ressources n6ccssaires pour repondre a la nouvelle demande avec la qualite 
de service requise est alors indispensable pour faciliter Tacces anx ressources 
pour des utilisateurs consideres par Toperateur comme prioritaii^es, 
20 Or, les references a des procedures de preemption des ressources dans 

rUTRAN presentes dans la norme 3GFP sont extremement succinctes et, pour 
Tessentiel, d^finissent simplement la regie suivante selon laquelle TUTRAN 
peut uniquemsnt mettre en oeuvre des mecanismes permettant de preempter des 
RABs avec une priority plus faible, dans un ordre de priorite ascendant 
25 Cependant, les entires pour affecter un niveau do priorite a un RAB par 
rapport a un autre RAB ne sont pas decrits dans la norme. La maniere de 
prioriser TaccSs aux ressources radio au niveau de TUTRAN^ ainsi que les 
diffferents cas d'utilisation de la procedure de preemption, sont done laisses 
libres d' implementation* H s'agit la de notions tres importantes pour les 
30 operateurs UMTS^ puisqu^elles jouent un role primordial en vue de definir 
strategic de partage et d'allocation des ressources radio du reseau d'acces pour 
differentes classes d*abonnes par exemple. 

Aussi, un but de la pr^sente invention est de definir un grand nombre de 
niveaux differents de priorite dans FUTRAN entre differents RABs 
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cojrresix>ndant h des demandes de service venant du CN, permettant 
d^optimiser la strategie de partage et deallocation d^ ressources du reseau 
d'acces UMTS en effectuant une priorisation des ressources radio entre les 
services et les abounds au niveau du reseau d'acces radio. 
5 Un autre but de la presente invention est de definir differents cas 

d'utilisation de la procedure de preemption des ressources radio m niveau du 
reseau d'acces UMTS utilisant la relation d'ordre de priorite qui a ete ^tabiie. 

La presente invention conceme done un procede de gestion des 
ressources radio dans un reseau de communication mobile de type UMTS, 

10 lesdites ressources radio 6tant allouees par un controleur d'acces radio d'un 
reseau dracoes radio du r&eau UMTS pour supporter une plurality de 
demandes de service envoyees par equipements utilisateurs k un reseau 
coeur du reseau UMTS, chaque service etant specifie par un ensemble de 
parametres de quality de service enregistres au sein d*une entite du reseau 

15 co&ur, chacune desdites demandes de service 6tant traitee par T envoi par le 
reseau coeur audit controleur de reseau radio d'une demande deallocation de 
ressources radio correspondante, comprenant uae requete de service support 
d'acces radio decrivant la qualite de service requise sous forme d'un ensemble 
do parametres RAB dont la valeur est definie par une raise en correspondance 

20 avec les parametres de qualite de service coixespondant du reseau coeur, ledit 
controle3Lir de r^eau radio 6tant pr6vu pour r^artir les ressources radio du 
reseau d'acces entre les differents services supports d'acc^ radio 
correspondant aux diff^rentes demandes de service et pour mettre en oeuvre 
une procedure de preemption desdites ressources visant k moduler I'allocation 

25 des ressources aux dits services supports selon un niveau de priorite associe h 
chacun d'eux^ de sorte a sattsfaire la qualite de service requise pour les services 
supports en fonction de leur niveau de priorite, ledit procede etant caracterise 
en ce que ledit niveau de priorite est defini pour chaque service support par le 
sous-parametre « priority level » du parametre RAB « Allocation Retention 

30 Priority », dont la valeur est determinee en prenant en compte d'une part, la 
valeur dudit param6tre de quality de service « Allocation Retention Priority » 
du reseau coeur et, d* autre part, la valeur d'au moins un parametre de qualite de 
service lie au type de service* 

Selon un mode de realisation de Tinvention, les paianietres de qualite 
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de service lies au type de service utilises pour la determination de la valeur 
affectee an soiis-paxamdtre « Priority level » definissant le niveau de priorite 
pour le service support correspondant, comprennent ie parametre « Traffic 
Class », 

5 Selon-mi autre mode de realisatiorij les parametres de quality de service 

lies au type de service utilises pour la detenuination de la valeur affectee au 
aous-parametre «Priority level » definissant le niveau de priorite pour le service 
support correspondant, comprennent en outre le paraniMre « Traffic handling 
Priority » pennettant de prioriser les services de type interactif les uns par 

10 rapport aux autres. 

Selon uae caracteristique, la procedure de preemption des ressources au 
niveau du r6seau d'acces est mis e en osuvre a la reception par le controleur de 
reseau radio d'au moins une nouvelle requSte de service support d*acces radio, 
dans le cas ou il n*y a plus de ressources radio dispooibles ou si les ressources 

15 radio necessaires pour satisfaire la qualite de service associee a ladite nouvelle 
requete sont iiisuffisantes. 

Selon une autre caracteristique^ la procedure de preemption des 
ressources au niveau du reseau d'accds est mise en o^uvre k la reception par le 
controleur de reseau radio d'au moins une demande de ressources 

20 supplementaires pour r<§pondre a une evolution du trafic sur ledit reseau 
engendre par au moins un service support deja actif au sein dudit r6seau, 
lorsqu'il n'y a plus de ressources radio disponibles ou si les ressources radio 
necessaires pour satisfaire la demande de ressources supplementaires sont 
insufiisantes. 

25 Avantageusement, dans le cas ot au moins deux services supports deja 

actifs au sein du reseau font Tobjet respectivement d'une demande de 
ressources supplementaires et ou les ressources necessaires pour satisfaire 
lasdites demandes sont disponibles, une 6tape de priorisation pour Tallocation 
des ressources est mise en oeuvre de sorte a determiner, en fonction du niveau 

30 de priorite associ^ h chacun desdits services supports, auquel desdits services 
supports seront affectees prioritairement les ressources suppl&nentaires, 

Avantageusementj dans le cas ou au moins deux services supports 
d'acces radio deja actifs au sein du reseau n'utilisent pas d'une fa90U optimale 
les ressources qui leur ont 6t6 allouees, une etape de priorisation est mise en 
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oeuvre entre lesdits services supports^ de sorte a diminuer les rcssources 
aliouees a ces dits services supports dans un ordre d^fini par le niveau de 
priorite associe a chacim desdits services supports* 

UinventioTi sera mieux comprise et d'autr^ particularit6s et avantages 
5 apparaitront a la lecture de la description d'ua exemple de realisation prefere 
qui va suivre, donnee imiquemetit a litre illustratif et non limitatif, la 
description faisant reference aux dessins annexes parmi lesqucis : 

- la figure 1 decrit T architecture d'un reseau de type UMTS et a deja ete 
d6crite ; 

10 - la figure 2 decrit la procedure deactivation d'un contexte PDP pour le 

domaine paquet et a deja ete decrite, et 

- la figure 3 illustre de fa9on schematique les differents niveaux 
d'utilisation des ressources dans FUTRAN et a sgalement deja et6 d6crite, 

Ainsi, comme precedemment explique^ I'UTRAN doit etre capable de 

15 repartir F integrality de ses ressources entre les differents utilisateurs du 
systeme, II est necessaire pour cela d'implementer au niveau du controleur de 
reseau radio de FUTRAN une procedure de preemption vis ant a faciliter 
Faeces aux ressources pour des service supports d'accfes radio ou RABs, 
consideres par Fop^rateur du reseau comme prioritaires, 

20 Pour ce fairCj F invention propose de definir un grand nombre de 

niveaux de priorite entre les difKrents RABs, utilises pour prioriser Faccfe aux 
ressources pour les RABs dans FUTRAN, et pour pouvoir choisir quel RAB va 
preempter quel autre RAB pour F allocation des ressources lorsque ces 
demieres sont insufiisantes ou indisponibles, 

25 Ces diff6rentes vaieurs de niveau de priorite sont done prevus pour etre 

utilises par les algorithmes de gestion des ressources et, plus particulierement, 
par ceux qui feront appel a une procedure de preemption des ressources, pour 
determiner Fallocation des ressources affectSes h chaque RAB au niveau du 
reseau d'acces radio lorsque plusieurs RABs sont en competition pour obtenir 

30 leg mSmes ressources. Les vaieurs de niveau de priorite selon F invention seront 
utilisees par la procedure de preemption lorsque les ressources n6cessaires pour 
satisfaire la demande d'un RAB donne ne sont pas disponibles ou bien sont 
insuffisantes au vue du niveau de charge courant dans le reseau d'acces. La 
procMxire de preemption est alors pr6vue pour utiliser ces vaieurs de niveau de 
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priori te selon I' invention associfies h chaque RAB pour determiner si itn RAB 
demandant a le droit de preempter des ressources au niveau du reseau d^acc^s 
et dans ce cas, quel(s) est (sent) le(s) RAB(s) qui verront ses (leurs) ressources 
preempt6es. 

5 Selon line caract6ristique importante de T invention, les differents 

niveaux de priorite associes aux differents RABs pour T allocation des 
ressources radio au niveau du reseau d'accfe doivent etre confignrables par 
Toperateur en fonction des parametres RAB envoy^s au RNC par le reseau 
coeur et, plus particulierement, par le noeud de service SGSN et/ou MSG du 
10 reseau coeur, Les differents parametres RAB sont en fait issus d'une mise en 
correspondance avec les parametres de qualite de service venant du reseau 
coeur vers le reseau d'acces. 

Parmi les parametres RAB, on trouve ainsi les parametres suivants : 

- « Traffic Class » ; 

15 - « Traffic Handling Priority >\ la valeur de ces parametres RAB etant 

obtenue respectivement par une mise en correspondance directe avec les 
parametres de QoS correspondant « Traffic Class » et « Traffic Handling 
Priority » li6s au type de service envoyes par le r6seau co&ur, 
et un parametre RAB He a un niveau de priorite de Tabonne : 

20 - « Allocation Retention Priority »^ forme par les quatre sous parametres 

suivants issus du parametre de QoS « Allocation Retention Priority » du reseau 
coeur : 

- « Priority Level » 

- « Preemption Capability» 
25 - « Preemption Vulnerability» 

- « Queuing Allowed » 

L* invention pi^voit en fait une nouvelle mise en correspondance des 
parametres de qualite de service du reseau coeur vers le reseau d'acc^s, de sorte 
a ce que la determination des quatre sous-parametres RAB qui integrent le 
30 parametre ARP prennent en compte non seulement la valeur du parametre ARP 
du reseau coeur, mais egalement les valeurs des parametres de QoS li6s au t>pe 
de service. 

Plus precisement, le niveau de priorite selon T invention pour la gestion 
de Pallocation des ressources est d^fini pour chaque RAB par le parametre 
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« Priority Level » du parainStre RAB « Allocation Retention Priority », dent la 
valeur est determinee en prenant en compte d'me part^ la valeur du param^tre 
« Allocation Retention Priority » du reseau coeur et, d' autre part, la valeur d'au 
moins un parametre de QoS He au type de service. Les parametres de QoS lies 
5 an type de service utilises pour la determination de la valeur affect^e au sous- 
parametre « Priority Level » pour la definition du niveau de priorite seion 
r invention comprennent dans un premier mode de realisation le parametre 
« Traffic Class », susceptible de prendre quatre valeurs. Dans un second mode 
de realisation, les parametres de QoS lies au type de service utilises 

10 comprennent en outre le parametre « traffic Handling Priority », susceptible de 
prendre trois valeurs et qui permet de prioriser, soit d'ordonner par niveau de 
priorite, les services de type interactif (c^est-a-dire ceux pour lesquels le 
parametre « Traffic Class » prend la valeur « Intemctive »), 

De cette fa9on, en utilisant le parametre de QoS « Traffic Class » et le 

15 parametre de QoS « Allocation Retention Priority » du reseau coeur, il est 
possible de definir jusqu'a dou2e valeurs pour le parametre « Priority level » 
entre les differents RABs et done, jusqu'a douze niveaux de priorite, 

De plus, en utilisant le paramtoe « Traffic Class », le parametre 
« Allocation Retention Priority » du reseau coeur et le parametre « Traffic 

20 Handling Priority », on pent definir jusqu'a dix-huit valexurs pour le parametre 
« Priority level » entre les difFerents RABs et done, jusqu'a dix-huit niveaux de 
priorite* 

Le tableau ci-dessous illustre un premier exemple de definition a partir 
du parametre « Priority Level », d*un niveau de priorite du couple 
25 service/abomie associe a chaque RAB, utilise pour la gestion de 
r alio cation/conservation des ressources au sein du reseau d'accfe : 
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Parametres de QoS du r^eau coeur 


Parametres RAB 


Allocation /Retention Priority 


Tramc Class 


Allocation / 

Retention 

jrnon.iy 


Priority 
Level 


Pre-emption 
Capability 


Pre-emption 
Vulnerability 


; Queuing 

Ail _i 

Aliowea 


Conversational 


1 


1 


Y 


N 


N 


Conversational 


2 


2 


Y 


Y 


N 


Conversational 


3 


3 


Y 


Y 


N 


Streaming 


1 


4 




Y 


N 


Streaming 


2 


5 


Y 


Y 


N 


Streaming 


3 


6 


Y 


Y 


N 


Interactive 


1 


7 


Y 


Y 


N j 


Interactive 


2 


8 


Y 


Y 


N i 


Interactive 


3 




Y 


y 


N 


Backgroimci 


i 


10 


Y 


Y 


N 


Backgromid. 


2 


H 


Y 


Y 


N 


Background 


3 


12 


N 


Y 


N 



La valeur Y attiibuee au parametre « Pre-emption Capability » indique 
que le RAB associe est susceptible de preempter les ressources d'aiitres RAB, 
la valeur N indiqiiant rinverse. De la meme fa^on. La valeur Y attribuee axi 
5 parametre « Pre-emption Vulnerability » indique que le RAB associ6 peut voir 
ses ressources preempted par d'autres RABs, la valeur N indiquant Tinverse, 

II decoule de Texemple present^ ci-dessus, la definition suivante d'un 
ordre de priorite entre les differents RABs pour T allocation/conservation des 
ressources a partir du parametre « priority Level », iequel est determine en 
10 prenant en compte pour chaque l^B d'une part, la valeur du parametre 
« Allocation Retention Priority » du r6seau coeur et, d' autre part, la valeur du 
parametre de QoS « Traffic Class » : 

RAB avec "priority Level'* - 1 > RAB avec "priority Level'' = 2 
RAB a.vec "priority Level" — 1 1 > RAB avec "priority Level" — 12. 
15 Ainsijj uu RAB avec ua niveau de priorite defini selon 1' invention 6gal a 

5 peut preempter les ressources allouees aux RABs ayant un niveau de priorite 
selon 1' invention aUant de 6 & 12, 

Le tableau ci-dessous illustre un second exemple de definition i partir 
du parametre « Priority Level », d'un niveau de priorite du couple 
20 service/abonne associe a chaque RAB, utilis6 pour la gestion de 
r alio cation/conservation des ressources dans le rSseau d'act^s, oii la valeur du 
paramdtre « Priority Level » pour chaque RAB est cette fois detemiinee en 
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preaant en compte, en plus de la valeur du parametre « Allocation Retention 
Priority » dn r&eau coeur et de la valeur dxi parametre de QoS « Traffic 
Class », la valeur du parametre de QoS lie au type de service « Traffic 
Handling Priority ». Cette exemple se rapporte a une configuration du reseau 
5 ot les services temps reel ne peuvent pas voir leurs ressources preemptees, 
comrae le montre la valeur N affectee au sous-parametre « Pre-emption 
Vulnerability » pour les services de ce type (« Conversational » et 
« Streaming »). 



Parata^tres de QoS du r^sesu coeur 


Parametres RAB 


/Mlocation /Retention Priority 


Traffic Class 


THP 


Allocation 

/ Retention 
Priority 


Priority Level 


Pre-emption 
Capability 


Pre-eniption 
Vulnerability 


Queuing 
Allowed 


Conversational 




1 


1 




K 


N 


Conversational 




2 


2 


Y 


H 


N 


Conversational 




3 


3 


Y 


N 


N 


Streaming 






4 


Y 


H 


N 


Streaming 




2 


5 


Y 


N 


N 


Streaming 




3 


6 


Y 


N 


: N 


Interactive 


I 


1 


7 


Y 


Y 


N 


Interactive 


2 


1 


7 


Y 


Y 




Interactive 


3 


1 


7 


Y 


Y 




Interactive 


1 


2 


8 


Y 




N 


Interactive 


2 




S 


Y 




N 


Interactive 




it 


8 


i Y 


Y 


N 


Interactive 


1 




9 


Y 


Y 


N 


Interactive 


2 


3 


9 


Y 


Y 


N 


Interactive 


3 


J 


9 


Y 


Y 


1^ 


Background 


F"-" 


1 


10 


Y 


Y 


N 


Background 




2 


11 


! Y 


Y 


N 


Backgiiaund 




3 


12 


N 




N 



10 Les niveaux de priorite tels qu'ils viennent d'etre definis seront utilises 



par les algorithines de gcstion des ressources pour prioriser Faeces aux 
ressources lori^ue plusieurs RABs sont en competition pour obtenir les memes 
ressources et, plus particulierement, par les algorithmes mettant en oeuvre une 
procedure de preemption, pour pouvoir detenuiner quel RAB va preempter les 
15 ressources de quel autre RAB lorsque les ressources devant etre allouees sont 
insuffisantes ou indisponibles. 

La procedure de preemption peut notamment etre utilisee a Tetape de 
controle d'admission, c'est-a-dire a la reception par le RNC d'uue notwelle 
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requete RAB, Une nouvelle requete RAB peut decouler, soit de retablissement 
d'un nouveaii RAB dans le reseau d'acces^ soit d'une procedure de mobilite 
d'lm RAB deja admis dans le reseau d'acces, 

Dans ce cas, en reference au schema de la figure 3, lorsque le ruvean de 
5 charge du systeme se trouve daxis la zone 2 ovt 3, e'est-a-dire qu*il existe soit 
des ressources disponibles mais celles-ci sont insuffisantes pour repondre a la 
nouvelle demande de telle maniere que les exigences de QoS soient assurees, 
soit qu'il n'y a plus de ressources disponibles, une procedure de preemption est 
utilisee par les algoritfames de gestion des ressources pour recuperer les 

10 ressources necessaires selon le niveau de priorite du RAB entrant et le niveau 
de priorite des RABs qui sont actifs dans le S3^teme. 

La procedure de preemption est egalement prevue pour etre utilisee 
pendant Tappel par le controle de trafic, en reponse a i'evolution du trafic d'un 
RAB deja actif au sein du reseau se traduisant par xine demande de ressources 

15 suppi&nentaires, lorsque les ressources dans le reseau pour satisfaire cette 
demande sont indisponibles ou sont insuffisantes. II s'agit alors d'un controle 
individueL La procedure de preemption permet de diminuer les ressources 
allou6es a un RAB qui possede un niveau de priorite plus faible et a re-allouer 
ces ressources relachees au RAB qui les demande et qui possede un niveau de 

20 priorite plus haut, 

Dans le cas oil le niveau de charge du reseau est en zone 1 et qu'il n'y a 
done aucvine restriction des ressources, ceM-ci doit n^anmoins Stre capable de 
r6agir aux variations de debit d'un RAB deja actif de telle sorte que ks 
ressoTirces ailouees a rutilisateur puissent s*ajuster dynamiquement aux 

25 besoins. Ainsi, au cas oh deux ou plusieurs utilisateurs demandeat 
simultanement des ressources supplementaires* 1^ algoritimies de gestion des 
ressources efifectuent une priorisation de 1' allocation des ressources en fonction 
des niveaux de priority associ6s a chaque RAB, de sorte que le RAB qui 
possede le niveau de priorite le plus haut soit servi prioritairement, 

30 Par contre, lorsquHl n'y a pas de restriction de ressources dans le reseau 

et si deux ou plusieurs utilisateurs n'utilisent pas d'une fa9on optimaie les 
ressources qui leur ont ete ailouees, les niveaux de priorite associes a chaque 
RAB conceme seront utilises dans le cadre du controle de trafic, de sorte a 
diminuer les ressources aUou6es. Dans ce cas, les RABs qui possedent un 
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niveau de priority plus faihle verront leurs ressoiirces redmtes en premier, 
ensuite ceux qm ont une priorite plus haute et fmalement ceux qui out ia 
priorite la plus haute, parmi les RABs concemes* 

Egalement, dans la zone 2 et 3^ d'une maniere similaire a la zone 1, si 
5 plxisieui^ utilisateurs ne font pas un usage optimal de leurs ressources, les 
niveaux de priorite associes a chaque RAB conceme seront utilises dans le 
cadre du controls de trafic, de sorte a diminuer les ressources aIlou6es. Dans ce 
cas, I'ordre dans lequel la diminution des ressources allou6es sera effectuee est 
defini par le niveau de priorite de chaque RAB conceme defini selon 
iO rinvention. 

Enfin, la proc6diire de preemption peut egalement etre mise en oeuvre 
pendant Tappel en r6poase a revolution de la charge dans le systeme, dans le 
cadre d'un controle global du trafic. Notainment, lorsque le niveau de charge 
du reseau est en zone 3, il est nccessaire de ramener les niveaux d 'utilisation 

15 d^ ressources k des valeurs plus stables, Dans ce cas, la procedure de 
preemption inise en ceuvre dans le cadre du controle de trafic vise a reduire les 
niveaux de cliarge dans le systeme. Pour ce faire, la procedure de preemption 
etablit un ordre parmi les RABs actifs dont les ressources allouees sont 
susceptibles d^etre diminuees, en utilisant les niveaux de priorite associes a 

20 chacun de ces RABs, Ceux qui ont la priorite la plus faible verront leurs 
ressources diminuer en premier lieu, suivis de ceux qui sont plus prioritaires 
pour enfiu conchire, si la charge dans le reseau n'est pas revenu a xm niveau 
acceptable, par ceux qui ont le niveau de priorite le plus 61qyL 

25 
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GLOSSAIRE 

Ce glossaire presente la liste des acronymes anglo-saxons utilises dans 
la presente demande de brevet. Ces acronymes sent definis dans ie cadre de la 
5 norme de telecommunication 3 GPP, 



3 GPP 


Third-Generation Partnership project (of ETSI) 


ETSI 


European Telecommunications Standards Institute 


GSM 


Global System for Mobile Communication 


UMTS 


Universal Mobile Telecommumcation System 


IP 


latemet protocol 


BTS 


Base Transceiver Station 


BSC 


Base Station Controller 


HLR 


Home Location Register 


SGSN 


Serving GPRS Support Node 


GGSN 


Gateway GPRS Support Node 


UTRAN 


UMTS Terrestrial Radio Access Network 


RNC 


Radio Network Controller 


QoS 


Quality of Service 


ARP 


Allocation Retention Priority 


PDF 


Packet Data Protocol 


THP 


Traffic Handling Priority 


IMSI 


International Mobile Subsciber Identity 


RAB 


Radio Access Bearer 
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REVENDICATIONS 

1. Proced6 de gestion des ressources radio dans im reseau de 
5 communication mobile de type UMTS> lesdites ressources radio etant allouees 

par nn controleur d'acces radio (RNC) d'un reseau d'acces radio (UTRAN) dii 
reseau UMTS pour supporter une pluralite de demandes de service envoy ees 
par des eqiiipements utilisateurs (UE) a un reseau cceur (CN) du reseau UMTS, 
ohaque service etaut specifie par ua ensemble de parametres de qualite de 

10 service enregistres au sein d'uae entity (HLR) du reseau coeur, chacune 
desdites demandes de service etant traitee par T envoi par le reseau caeur audit 
contrdleur de r&eau radio (RNC) d'une demaade deallocation de ressources 
radio corr^pondante, comprenant tme requete de service support d'acces radio 
decrivant la qualite de service requise sous fomie d*ua ensemble de parametres 

15 RAB dont la valeur est d6fime par une mise en correspondance avec les 
parametres de qualite de service correspondant du r6seau coeur, ledit 
controleur de reseau radio (RNC) etant prevu pour repartir les ressources radio 
dm reseau d'acces (UTRAN) entre les differents services supports d'acces radio 
correspondant aux differentes demandes de service et pour mettre en oeuvre 

20 une procedure de preemption desdites ressources visant a moduler T allocation 
des ressources axix dits services supports selon un niveau de priorite associe k 
cliacun d*eux, de sorte a satisfaire la qualite de service requise pour les services 
s\xpports en fonction de leur niveau de priorit^j ledit precede etant caracterise 
en ce que ledit niveau de priority est defmi pour chaque service support par le 

25 sous-paramStre « priority level » du parametre RAB « Allocation Retention 
Priority », dont la valeur est determinee en prenant en compte d'une part, la 
valeur dudit parametre de qualite de service « Allocation Retention Priority » 
dxi reseau coeur et, d' autre part, la valeur d'au moins un parametre de qualite de 
service lie au type de service. 

30 

2, Proced^ selon la revendication I, caract6rise en ce que les parametres 
de qualite de service lifes au type de service utilises pour la determination de la 
valeur affect6e au sous-parametre « Priority level » definissant le niveau de 
priorite pour le service support correspondant, comprennent le parametre 



wo 2005/084061 



21 



PC r/FR2005/000130 



« Traffic Class »- 

3, Precede selon la revendi cation 2, caracterise en ce que les parametres 
de qualite de service lies au type de service utilises pour la determination de la 
5 valeur affectee au sous-parametre « Priority level » definissaat le niveau de 
priorite pour ie service support correspondant, comprenneat en outre le 
parametre « Traffic handling Priority » permettant de prioriser les services de 
type interactif 1^ uns par rapport aux autres. 

10 4. Procede selon Tune quelcouque des revendications prec6dentes, 

caracterise en ce que la procedui*e de preemption des ressources au niveau du 
reseau d'acces (UTRAN) est mise en oeuvre a la reception par le contrSleur de 
reseau radio (RNC) d*au moins une nouvelle requete de service support 
d'acces radio, dans le cas oix il xi'y a plus de ressources radio disponibles ou si 

15 les ressources radio nScessaires pour satisfeire la qualite de service associde h 
ladite nouvelle r^uete sont insuffisantes, 

5, Proc&ie selon I'un© quelconque des revendications pr6c6dentes, 
caracterise en ce que la procedure de preemption des ressources au niveau du 

20 reseau d'acces (UTRAN) est mise en oeuvre a la reception par le controleur de 
reseau radio (RNC) d'au moins une deaiande de ressources supplementaires 
pour repondre a ime evolution du trafic sur ledit reseau engendr^ par au moins 
un service support deja actif au sein dudit rfeeau, lorsqu'il n*y a plus de 
ressources radio disponibles ou si les ressources radio necessaires pour 

25 satisfaire la demande de ressources supplementaires sont insuffisantes. 

6* Procede selon Tune quelconque des revendications precedentes, 
caracterise en ce que, dans le cas oxi au moins deux services supports deja 
actifs au sein du reseau fent Tobjet respectivement d'une demande de 
30 ressources supplementaires et ou les ressources necessaires pour satisfaire 
lesditcs demandes sont disponibles, une etape de priorisation pour Taliocation 
des ressources est mise en oeuvre de sorte a detemiiner, en fonction du niveau 
de priorite associe h chacun desdits services supports, auquel desdits services 
supports seront affect^es prioritairement les ressources suppl6meataires. 
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7. Proc6d6 selon Tune quelconqiie des revendications precedentes, 
caracterise en ce quiS dans le cas ou au moins deux services supports d'acc^s 
radio deja actife au sein du reseau n'utilisent pas d'une fa^on optiniale ks 
5 ressources qui leur ont 6t6 allouees, une etape de priorisation est mise en o&uvre 
entre lesdits services supports, de sorte a diminuer les ressources allouees a ces 
dits services supports dans un ordre defini par le niveau de priorite associe a 
chacun desdits services supports. 
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QqS demandee 

• Glasse de trafic,„,etc 



QoS negoclee au SGSN 
• Ciasse detrafic 
Allocation/retention priorrty 
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Param§tres RAB=s 

• Class.s de trafic 

* AllocatfoiVretention priority 






UMTS 




RNC 
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SGSN 

^ QoS negoclee par le GGSN ^ 



QoS negociee parie 
SOSM 8tls GGSN 



Fig. 2 
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Fig. 3 



